This article reinforces why we struggle to manage technical debt as an industry.
First off, technical debt is expensive. The article states that on average, about a quarter of all IT budgets are allocated to handling technical debt each year. This figure is set to rise, as 68% of organizations say their technical debt will increase in 2022.
That’s a really big number. So, what really is technical debt and why is it hard to avoid?
If it really is as simple as “the downside of taking the quick option” then it can’t it be avoided by not cutting corners?
If we investigate in more detail, we find it’s not that easy because debt can be introduced in many ways, many of which are hard to prevent.
Adding features to a system but not making the changes in the intended way will create debt. But how do you know what the author intended? Are the authors still around? Maybe the documentation isn’t good enough, or the developer simply didn’t look.
Building the same function twice in different systems is debt. But how do you know if what you’re building hasn’t been built before? Very few firms have good inventories of what exists that all developers and processes can interrogate. And if they do, how shareable is the software anyway?
This is a reason why legacy elimination or system consolidation is so important. It’s also why firms that have done a lot of acquisition, particularly struggle.
Not following the best development practices when writing software also creates debt. These best practices are subjective and there’s usually not one right answer. It will depend on how well defined your SDLC is and how good your developers are at following it. Effective code reviews and conscientious adherence to test driven development are a must.
So what? —Be pro-active. To get technical debt under control we need to accept it as a natural consequence of the software development process and tackle it at the source with the right engineering processes.
Link to the original article here.